STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL96.LZH/t0120/text0009.txt

Text File | 1996-03-07 | 6.1 KB | 113 lines

> Okay, it's time for me again to throw in an idea here... There's been some
> discussion back and forth between people about how to best handle the
> information interchange between the networking machines, and there's been
> quite a few good (And a slightly less amount of bad) suggestions.

Yes. It's nice to see that so many people have ideas. :-)

> Now, the networking package could be arranged so that, no matter which
> machine initiates the networking sequence (ie, one random machine
> initially sends out a networking initiation message throughout the net),
> each machine should check its own capabilities to see which one would be
> best suited to act as the controlling unit. It would be natural for an
> accellerated machine to handle the most CPU-stealing stuff instead on a
> standard-configuration Falcon.

This sounds okey to me.

> Therefore, I have made a temporary mental sketch of the initiation
> sequence that could be used. Here's the idea.
>
> In any given network, be it two players or fifteen, a single machine
> should send out a message on the net that a networking game is to be
> started. The exact message to be sent does not have to be clear to discuss
> this feature - that is a matter for the programmers to decide upon. The
> first message should simply be to detect the numer of machines in the
> network, and to assign a unique identifier to the diferent machines. (The
> machines that initates the sequence could be #0, the next #1,and so on)
>
> Following that, a message asking each machine to check the available
> hardware should be issued. This should involve a check of drawing speed on
> a set area of the playing area, preferably one that involves complex
> shapes to _really_ test the frames/second ration. This should take but a
> second if the proper code is used. Then the fastest machine is assigned as
> the master server, and takes over msot of the network handling. (To make
> things easier, if the fastest machine is not the same one that started th
> network, assigning new identifiers to each machine, with the new master
> being #0 should be considered.

Do you realy have to first assign a unique identifier for each machine and
when check the harware status and when reorder the identifier? Couldn't this
be done at the same time? I mean, one machine (the first one that jumps into
network mode) will ask the others about their hardware status and when it
handles out the unique identifier. You must also know how many players
it should watch for. This could easiely be done by a menu there you type in
how many players there is. Another easier solution would be if you deceided
your self which compter will be the master. Don't you know what you have inside
your own computer? ;-)

> Anyway, at this point we will have a working network.
>
> Then for the interchange of game information. What we really need to know
> is how much information needs to be transferred at the point the game
> starts. For each individual player, the absolute minimum would be this:
> - Position within the level. This will have to be three words or longwords,
>   depending on the nature of the game (I have absolutely no clue!)
> - Facing of the player. In which direction is he facing? This is vital to the
>   other machines drawing the player's sprite.
> - Movement speed. Logical.
> - (Optional) Sprite identificator. We might want to use different sprites for
>   for each player depending on the weapong he/she wields. It wouldn't be
>   the most logical thing if player #2 is using a machine gun but all others
>   see him using a scythe, right?
> - Additional sprites. If a blowtorch has been fired by the player all others
>   should be able to draw the flame, right? This will have to include
>   direction and speed of the additional item(s)
> - Movement of enemy sprites. It would't be good if ten machines didn't
>   synchronize the movement of enemy sprites. The logics included would be
>   hilarious, though - Just think of it guys ;-) (This package could get big)

If we are going to have an midi-maze mode, and I think many wants one, you
wouldn't need to calculate any AI as there isn't ny monsters just the
players. Maybe we could have on midi-maze mode with up to 15 computers (or whatever
the maximum is before the game gets to slow) and one mode with monsters but
maybe only with a maximum of 4 computers or less.

> There might be more I don't remember. To reduce the networking required,
> it would be a good idea to let the master server calculate the AI of the
> enemy sprites instead of having all the machines do it individually. That
> way the networking load would be reduced and (possibly) the redraw speed
> of each individual machine increased, especially if the server does
> nothing but maintain the network. I, for one, support the idea, seeing how
> it can lessen the load on the other machines.

This will only be neccesary if you are not using the midi-maze mode and
if you use it you will either have to use fewer computers (like in doom, 4)
or a master server computer like you said. If you have an master server
you might be able to use more computers than 4. You still have to send all
the information over the net where the monsters are though.

> These are the first ideas. No doubt they will be changed, though I believe
> the basic idea might survive the needs of the game. I'm looking forward to
> hearing constructive criticism on this one, as well as other ideas.

I think it's a good start.

> And now for something completely different: When will there be a new beta
> version of BM out for the rest of us to see? I'm eager to see how far the
> texture-mapping has come!

I got a letter from Doug today and he said that he have now done the texture
mapping of the walls, ceiling and floor now. He have also done lightning effects
and z-shading for the ceiling/floor but not yet for the walls. This will be
done before he releases it. He uses only one texture for the walls and one for
the ceiling/floor, but this have to do with the WAD loader and this will also
be fixed before he releases it and he will also optimise it even more.

I think we will see this version soon as he is very fast. Maybe on monday if
it all goes well. :-)
I can't wait to see it. :-)))))

//Magnus Kollberg